The present invention relates to a system for face-up printing of documents, and in particular to a system for face-up printing of documents rendered in Tag Independent File Format (TIFF).
Computer applications are often used to create multi-page documents that may be easily and conveniently edited on a computer before a final version is printed to a printer, fax machine, or other such printer device. Existing computer applications typically transmit printing instructions, including page data, page order, etc. to the printer device after being prompted by a user. Printer drivers typically provide the necessary interface between the application and the printer device so that the document is printed as instructed by the application. For example, an application may provide page data to a printer in sequential page order. In order to collate the document preserving the proper page order, a face-down printer should print the pages in the sequential order received by the application while a face-up printer should the reverse the sequential order of pages received by the application. The printer driver or printer will usually perform the function of reversing the sequential order of pages where appropriate.
FIGS. 1 and 2 illustrate one existing system by which instructions from a computer application are transmitted to a printer device. In these FIGS., application 10 initiates a print job through a graphic device interface (GDI) 12. Application 10 may be a word processor, spreadsheet, browser, database program or some other program that runs on an underlying operating system, such as Windows 9x, Windows Me, Windows NT/2000, Windows XP, etc.
The GDI 12 will initially obtain instruction from the printer driver 14 on how to render text characters and other graphical objects on the particular printer device such as the bi-directional printer 16 that is associated with the printer driver 14. In some situations, the printer driver 14 and the GDI 12 may be written in 16-bit code, while the underlying operating system performs mathematical operations in a 32-bit code. In those instances, the 16-bit GDI may pass the print job to a 32-bit GDI 18. Either the 16-bit GDI 12 or the 32-bit GDI 18, whichever is appropriate, may then initiate a spooler process 20.
The spooler process 20 may route the print job to the printer 16 through a router 22 capable of sending the print job to a selective one of any available print providers, which may be a local print provider 24 or a network print provider (not shown). Where printing is to be performed locally, the router 22 sends the print job to a local print provider 24 which writes or “spools” a raw spool file 26 to a disk, usually located on the host computer for later access. This is done to avoid waiting for the printer 16 to complete the print job before control is returned to the application. These steps from initiating the print job to writing to spool file 26 may be repeated many times, and data may be appended to spool file 26 until the application 10 signals that the print job is complete by using, for example, an EndDoc() function. Local print provider 24 may also start a port thread 28 that preferably monitors system resources and determines the best time to start playing back or “de-spooling” the spool file 26 to the printer 16.
When printing is to be performed by a network printer device attached to a network server, the router 22 may route print jobs to a network print provider (not shown). In Windows 9x operating systems the spool file 26 is typically spooled to and de-spooled from the disk on the host computer just as are local print jobs. The network server is contacted only during de-spooling to receive the print job. Windows NT/2000® client machines handle print jobs to network printer devices differently; these machines use remote procedure calls (RPCs) to call the necessary printing application program interfaces (APIs) on the network server. In these NT/2000 scenarios, spooling and de-spooling are handled by the network server. This RPC method can also be used in conjunction with Windows 9x operating systems, if desired.
When the port thread 28 determines that the spool file 26 should be de-spooled, a command, such as StartDoc() function call, may be sent to print processor 32 which then instructs the local print provider 24 to read data from the spool file 26 and forward it to the printer 16 through a port monitor 36 and through the physical port 38 connected with the printer 16. Because the printer 16 is a bidirectional printer, the data from the spool file may also be sent through a language monitor 34. The language monitor 34 and port monitor 36 may be separate components or may be integrated into one monitor. This process of reading data from a spool file 26 and forwarding it to the printer 16 may be repeated several times to complete a print job. This is typically repeated until the end of the file is reached or the print job is cancelled. The combination of spooler process, router, local print provider, print processor, language monitor and port monitor may be referred to collectively as a “spooler” 30.
The system illustrated in FIGS. 1 and 2 employs a “raw format” spool file, i.e. a spool file that is formatted for the specific printer device that is to be used. Accordingly, prior to spooling data to the spool file 26, the application 10 uses the GDI 12 to access the printer driver 14 to identify the format with which graphical objects are rendered on the specific printer 16, and writes to the spool file 26 in that format.
Unfortunately, each model of printer device or series of related models of printer devices will typically have its own unique driver that is either stored on the computer running the application or stored on firmware in some high-end printers. For that reason, using the previously described system to implement application-specific printer instructions across a variety of printing devices may require that the application be compatible with a multitude of existing printer drivers and their associated rendering formats, and also be updated for compatibility with drivers for newly introduced printer devices.
Furthermore, with respect to face-up printing, the aforementioned system requires that the last page of a document be rendered in the spool file before the sheets are printed so that they may be de-spooled in reverse sequential order. This requires storage of the rendered data on the host computer until the entire print job is rendered. When compared to immediate de-spooling of the page data to the printer, these processes can be slow and require expensive hardware and firmware or additional software.
Some of these difficulties can be alleviated through the use of Enhanced Metafile (EMF) files, i.e. device-independent files that contain graphic device interface (GDI) calls that reproduce an application's graphic objects on a printer. EMF files are used to quickly record the device independent printing instructions for a document and return control to the user. After control is returned to the user, the function calls stored in the EMF file are played back to the printer driver associated with the printer in the background.
FIGS. 3 and 4 show one existing system for transmitting instructions from an application to a printing device that uses EMF files. The system shown in these FIGS. usually commences when an application 40 initiates an EMF-format print job through a GDI 50 for a designated printer 68. GDI 50 accesses the printer driver 52 associated with the designated printer 68 to determine whether the driver 52 supports EMF spooling. If the driver 52 supports EMF spooling, GDI 50 writes the instructions for rendering the object in EMF format. In this example the Windows 95® spooler process is 32-bit code, so the GDI 50 passes the print request to the 32-bit GDI (GDI32) 56. GDI 32 subsequently passes the print job to the spooler subsystem 70, which initiates a spooler process 58.
The spooler process 58 passes the print job through a router 60 which routes the print job to a print provider 62 that is connected to the designated printer 68. In this example, a local print provider 62 is used, but a network print provider may also be used. If a network print provider is used, the process employed by the network printer to spool the print job has been discussed with respect to FIGS. 1 and 2. The router 60 may route the print job to the print provider 62 through one or more job requests. For example, in a multi-page print job, each page of the document may comprise a single job request.
The local print provider 62 creates a job description file 64 and adds a record to the job description file 64 each time it receives a job request until all the EMF page files have been spooled and each EMF file name and location is recorded in the job description file 64. When information about the last EMF file in the print job has been recorded, the local print provider 62 will send an EndDoc() function call to the spooler process 58, which signals that the print request is spooled and ready for de-spooling. For multi-page jobs, these steps from initial spooling request 41 to job description file recording 48 are repeated for each page of a print job.
When EMF file spooling is complete, the spooler process 58 sets a ReadyToPrint attribute on the print job and initiates an event 49 that signals the port thread 66 that a print job is available for printing. Port thread 66 responds to this event by determining the best time to start the de-spooling process and, at that time, loads the print processor 72. The print processor 72 will determine that the file format is EMF and call GDI32 56 with a function call 82.
GDI32 56 then reads the job description file 64 which provides the locations of the EMF files associated with each page of the print job. GDI32 56 relays the location of each EMF file, one page at a time, to the GDI 50.
GDI 50 accesses the printer driver 52 associated with the designated printer 68 chosen in application 40, reads page-rendering instructions from the spooled EMF file 54 for the particular page it has received from the GDI32 56, and passes them one at a time to the printer driver 52 which uses as many instructions as are necessary to render the first part of the page. When the 16-bit printer driver 52 renders a part of the page, it passes the printer-specific raw page data back to the GDI 50 which, in turn, passes the raw data to GDI32 56. GDI32 56 then passes the raw data to the spooler process 58 which then follows the same procedures it would for a raw format files as explained above.
Spooler process 58 calls the router 60 to route the print job to printer device 68. In this example, illustrated in FIGS. 3 and 4, the router 60 sends the print job to a local print provider 62. In other scenarios, the router 60 may send print jobs to a network printer through a network print provider (not shown). In this local printing scenario, the router 60 calls the local print provider 62 with the print job. Local print provider 62 invokes the language monitor 74 with a WritePrinter function call to send data through the physical port 78 connected with the bidirectional printer 68 specified previously.
A language monitor 74 is used in this example because the destination printer device 68 is a bidirectional printer. When non-bidirectional printers are used a port monitor 76 would be invoked instead of the language monitor 74. A language monitor 74 and port monitor 76 may be separate components or may be integrated into one monitor. The language monitor 74 calls the port monitor 76 to send print job data to the printer 68. The port monitor 76 then sends the raw data through the physical port 78 to the printer 68.
Parts of EMF pages are processed in this manner and printed until an entire page is printed. GDI32 56 then gets the path to the EMF spool file for the next page and calls GDI 50 to use the instructions in that EMF file to render the next page of the print job. The print job is finished when all the paths to EMF spool files are used up.
Though the use of EMF files avoids the complexity of ensuring that a given application is compatible with the wide array of drivers for printer devices, printer processes that employ EMF files still require that, with respect to face-up printing, the last page of the document be rendered in the spool file before the sheets are printed.
If the printer device contains no firmware, as is often the case, the print data must be fully rasterized into a bitmap of the entire side of the sheet or page. The size of the bitmap is the product of the dots per inch (dpi), the square area of the printable image, in inches, and the bit-depth. For example, a 360 dpi, 24-bit image on an 8½×11 inch sheet of paper would require 36.34 Megabytes of space if fully rasterized. As another example, a double-sided, eight sheet 24-bit full color brochure printed in 720 dpi full photographic quality would require 2.32 Gigabytes storage. For an InkJet printer without firmware to print face-up, it would need a large hard drive and sufficient memory to cache at least one side of a sheet, i.e. 145 Megabytes. The size of such files can present a considerable impediment to face-up printing.
Other processes, such as those used in conjunction with Windows NT and 2000 may use printing processes that use raw format files and EMF files differently than those just described, such as passing the entire EMF data for all pages to the GDI 50 in one pass, rather than one page at a time, or passing the EMF data directly to the print server without rendering the print job on the client when the EMF data is to be queued on a print server. A mirror copy of the driver on the server renders the EMF data instead.
FIG. 5 shows one such other process. Typically, a user will employ an application 100 to create a print job by calling GDI 102 functions. The GDI 102 and/or application 100 will then call a driver 104, such as the Winspool.drv which is a client interface into the spooler. This client interface exports the functions that make up the spooler's 32-bit API and provides for access to the server. The print job is then forwarded to the spooler's API server 106, such as Spoolsv.exe which can be started at the same time as the operating system. This API server module exports an RPC interface to the server side of the spooler's Win32® API. This module implements some API functions, but most function calls are passed to a print provider by means of the router 108, such as spoolss.dll.
The router 108 determines which print provider to call, based on a printer name supplied with each function call, and passes the function call to the correct provider 110, 112 or 114. If the selected printer is managed by the client system, the print job is handled by the local print provider, such as localspl.dll 110. Printers managed by the local print provider 110 do not have to be physically local to the client; they may also be directly connected to network cards or wireless interfaces without using a server. When these printers are used, the print job is passed to the kernel-mode port driver stack 116 and on to the printer 118.
When a printer connected with a Windows NT/Windows 2000 server, and its associated GDI 120 and driver 122, are selected, the router 108 directs the print job to the network print provider that redirects calls from the client's router to the network server's spoolsv.exe process 124 which forwards the print job to the network server's router 126. Because the network printer is local to the print server system, the network server router 126 routes the job to the server's local print provider 128. The job is then directed to the server's kernel-mode port driver stack 130 and out to the selected network printer 132.
Remote printers may also be used with these systems. When a remote printer is selected, the client router 108 may direct the print job to the local print provider 110 which will forward the print job to the kernel-mode port driver stack 116 and on to the remote printer 142 using a network protocol. When the local print provider 110 accesses a remote printer 142, the provider 110 uses a port monitor that can use network protocols recognized by the remote printer or its server.
Printers managed by non-Windows NT/2000 servers (e.g., Novell servers) may also be accessed through this print system. This may be achieved by using a local print provider 110 which directs the print job to the kernel-mode port driver stack 116 and on to the printer's server 136 using a type of network protocol. The server 136 then directs the job to the destination printer 140. This may also be achieved using a customized print provider 114 which sends the job to the kernel-mode port driver stack 116 which uses a network protocol to send the job on the printer's server 134 which then directs the job to the destination printer 138.
An example of these printing processes may be explained with reference to FIG. 6 which illustrates a Windows 2000 print process. In this process, an application 150 is used to initiate a print job using the Graphics Device Interface (GDI) 152. When the print job's initial output file is in raw format (not EMF) 154, the printer driver's printer graphics DLL 156 works in conjunction with the GDI 152 to create a print job that is sent to the client interface 160 of the spooler. Client interface 160 sends the job to the API server 162 which forwards the job to the router 164. In this example, the router 164 sends the job to the local print provider 165 as it is a local print job.
Within the local print provider 165, a print job creation API 168 is invoked. This APT 168 accesses the printer driver's printer interface DLL 174 and creates a job spool file 176. The job creation API 168 also forwards job information to the job scheduling API 170 which initiates a job scheduler thread 172.
At this point, the file format is checked 178. If the initial job file is in a raw format (not EMF), the job is sent to the language monitor DLL 182 and on to the port monitor 184 which sends the job to the kernel-mode port driver stack 186. Port driver stack 186 sends the job to the selected printer 188 for final printing.
When an application 150 creates a print job with GDI 152 in EMF format, the print job is sent 154 to a client spooler interface 160, which sends the print job to the API server 162 which forwards the print job to the router 164. Again, in this example, the router 164 sends the print job to the local print provider 165 because the print job is local.
Within the local print provider 165, a print job creation API 168 is invoked. This API 168 accesses the printer driver's printer interface DLL 174 and creates a job spool file 176. The job creation API 168 also forwards job information to the job scheduling API 170 which initiates a job scheduler thread 172.
At this point, the file format is checked 178 by the print processor 192. If the initial job file is in EMF format, the print job is sent to the print processor DLL 180 which directs the print job back to GDI 152 for conversion to raw format with the help of printer interface DLL 174. The converted print job is then sent back through the spooler client interface 160, APT server 162 and router 164 to the print provider 165. In the local print provider, the job is processed by the print job creation API 168, job scheduling API 170 and job scheduler thread 172. Because the job is now in raw format, the job is sent to a port manager 194 including a language monitor DLL 182 and on to the port monitor DLL 184 and kernel-mode port driver stack 186 before arriving at the destination printer 188.
What is desired, then, is a simple, cost effective system of achieving collated, face-up printing without the added complexity, expense, and delay of current implementations. What is further desired is a system of achieving face-up printing that may be used across a wide variety of existing printer devices as well as future printer devices.